(8 previous messages)

rmartin , Mar 13, 2001 03:05pm EDT ( 1.2.2.1) Uncle Bob  Expressiveness and language choice. Language certainly makes a difference; but any language can be written well. I don't mind C or C++. There are certainly cases where those are the best languages for the job. DSP code, if not written in assembler, is probably best written in C. Hard embedded real time apps are well done in C++. And many web apps or MIS/IT apps are nicely done in Java. However, I think there is a trend in language that will become more and more evident as the decade progresses. I think we are seeing an end to the emphasis on statically typed (type-safe) languages like C++, Java, Eiffel, Pascal, and Ada. These langauges force you to declare the types of variables before you can use them. As this decade progresses I expect to see an ever increasing use of dynamically typed languages such as Python, Ruby, and even Smalltalk. These languages are often referred to as "scripting langauges". I think this is a gross injustice. It is these languages, and languages of their kind that will be mainstream industrial languages in the coming years. Why do I think this? Because these languages are much much easier to refactor. What's more they have virtually zero compile time. Let me address each issue in turn. As an industry we became enamored of type-safety in the early 80s. Many of us had been badly burned by C or other type-unsafe languages. When type-safe langauges like C++, Pascal, and Ada came to the fore, we found that whole classes of errors were eliminated by the compiler. This safety came at a price. Every variable had to be declared before it was used. Every usage had to be consistent with its declaration. In essence a kind of "dual entry bookeeping" was established for languages. If you wanted to use a variable (first entry) you had to declare it (second entry). This double checking gave the compiler vast power to detect inconsistency and error on the part of the programmer; but at the cost of the double entries, and of making sure that the compiler had access to the declarations. With the advent of agile processes like XP, we have come to find that unit testing is far more important than we had at first expected. In XP we write unit tests for absolutely everything. Indeed, we write them before we write the production code that passes them. This, too, is a kind of dual entry bookeeping. But instead of the two entries being a declaration and a usage, the two entries are a test and the code that makes it pass. Again, this double checking eliminates lots of errors, including the errors that a type-safe compiler finds. Thus, if we write unit tests in the XP way, we don't need type-safety. If we don't need type-safety, then its costs become very severe. It is much eaiser to change a program written in a dynamically typed langauge than it is to change a program written in a type-safe language. That cost of change becomes a great liability if type-saftey isn't needed. But there is another cost; and that is the cost of compilation and deployment. If you want to compile a program in C++, you must give the compiler access to all the declarations it needs. These declarations are typically held in header files. Each header file containing a declaration used by the program must be compiled by the compiler. If you have a program with N modules, then to compile just one of them, you may have to read in all N header file. With a little thought you'll realize that this means that compile time goes up with the square of the number of modules. As code size increase, compile time rises in a distinctly non-linear manner. For C++ the knee of the curve comes at about half a million lines. Prior to that point, compiles are pretty short. After that point compile times start to stretch and can get abusrdly long. I know of one company that compile 14.5 million lines of code using 50 sparc-20s overnight. This massive compile time can be mitigated by making good use of dependency management. By carefully controlling the coupling of your modules you can reduce compile time to be proportional to NlogN. But even this can be very long for large projects. Java found a way out -- sort of. In Java declarations are compiled and stored in .class files. To compile a module requires only that the declarations be read from the .class files of the used classes. Transitive dependencies are not followed. Thus, java compile times can be drastically smaller than C++ compile times. Still, I often run into clients who have java compile times that runs close to half an hour or more. By using good dependency management, and very fast compilers, I think this can be drastically reduced. But the problem still exists. Dynamically typed language, however, have virtually zero compile time. There are no declarations to hunt down. Compilation can occurr while the code is being editted. As projects get larger and larger, this ability to be instantaneously compiled will become ever more important. Finally, there is the issue of deployment. In C++ or Java, if I change a base class, I must recompile and redeploy all .class files of classes that are derived from that base. (Java folks, you can try to get away without doing this, but you'll be sorry.) Thus, even a small change to a single class can cause large redeployment issues. In dynamically typed langauges, redeployment problems are not eliminated, but they are vastly reduced. So, Bob Martin's prediction for this decade: Keep an eye on languages like Python, Ruby, and Smalltalk. They are likely to become extremely important.

claird , Mar 14, 2001 02:26pm EDT ( 1.2.2.1.1) Expressivity Steven Majewski (who's made several appearances before in ITworld.com articles) reminded me that Matthias Felleisen (who's made several appearances before in ITworld.com articles) aimed for a precise definition in his "On the Expressive Power of Programming Languages". Readers might find this pertinent to the current discussion.

twinercm , Mar 14, 2001 02:52pm EDT ( 1.2.2.1.2) Expressiveness and language choice Hi Robert, I just felt it necessary to put a reason or two for statically (or at least strongly typed) languages. Biggest reason for strong typing, you know what type of object you deal with. As this can be read as many things I'd just like to qualify. I have done programming in FoxPro (1yr), which is difficult to mention the word type around. In mail system I implemented once the various mail was sorted into bags of a fixed weight/number. This was calculated using a straight division. The result was then used to fill the bags. Problem was that although the value before hand was an integer, it was now a float and its rounding upon use was incorrect for the application. This was found out after a long costly search (although thankfully not as long as the implementation). Result was having to use INT() around the variable. This was not the only instance of this problem but its one that stuck in my mind because I knew C++. I had acted in the belief that the type system would be of a sufficient level. This made an ass out of me and umption. (I mention this to show there was blame at my feet as well) When I started using C++ again, I felt a great relief. There was never any doubt of what was going on and I never found any problem with this approach. Using dlls and an abstract interface one can easily adapt to add new types should they be needed. Second, not so big reason is that of maintainability (obviously linked). Trawling through fox code gave me a great distaste for this, as you only know the type of an instance when you see a side effect of the type. Having a variable stay consistent throughout different code block makes it far easier to track. Yes these are tired reasons, but none the less valid. I would also like to see some data on the comparisoms of ease of refactoring vs maintainence difficulties against a variety of languages. For example whilst a scripting language may be easy to change, is change more necessary than a statically typed language, is it really lest costly for large systems etc. Re: unit tests making type safety irrelevant. How can the tests make sure every possible use of a loosely typed language is catered for. When you throw objects into the equation aren't you complicating matters further? Whilst the use of so's aren't a c++ standard, most environments allow for them. Most compilers also implement decent precompiled headers (and of course the symbol tables they contain). Java of course gets a boost in that it is already standardised. I would also argue that loosly typed languages, whilst giving a quick "compile" time, often leave bugs until run time that strongly typed languages don't. Whilst unit tests could alleviate this, I still worry that loose typing would place an even greater effort on them (thus restricting development of used code). I agree with the deployment issue, to an extent. It is possible in most environments to allow objects (be they .class or somewhere in a dll) to be loaded from a central system. (of course replicating this to global sites still provides a knock on issue). This means change it in one place it works for all (given the app/environment checks for newer versions instead of using cached ones). (of course this applies to scripted languages as well). So whilst I see the use of scripting languages increasing, due them just being extremely useful, I still see a huge place for strongly typed languages. These will continue to dominate in places that system stability is paramount, such as billing, server and os software etc. Just thought it best to state that I think perl for example is a great little language. The my is the wrong way round but hey, no language is perfect:). Chris

 
(68 following messages)